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rd , 



This Technical Specification (TS) has been produced by the ETSI 3 Generation Partnership Project (3GPP). 
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These should be interpreted as being references to the corresponding ETSI deliverables. The mapping of document 
identities is as follows: 

For 3 GPP documents: 

3G TS I TR nn.nnn "<title>" (with or without the prefix 3G) 

is equivalent to 

ETSI TS I TR Inn nnn "[Digital cellular telecommunications system (Phase 2+) (GSM);] Universal Mobile 
Telecommunications System; <title> 

For GSM document identities of type "GSM xx.yy", e.g. GSM 01.04, the corresponding ETSI document identity may be 
found in the Cross Reference List on www.etsi.org/key 
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Foreword 

This Technical Specification has been produced by the 3 GPP. 

This TS specifies the Radio Link Protocol (RLP) for circuit switched data transmission within the 3 GPP system. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of this TS, it will be re-released by the TSG with an identifying 
change of release date and an increase in version number as follows: 

Version 3.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 Indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the specification; 
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1 Scope 



This Specification specifies the Radio Link Protocol (RLP) for circuit switched data transmission within the GSM and 
UMTS PLMN. RLP covers the Layer 2 functionary of the ISO OSI Reference Model (IS 7498). It is based on ideas 
contained in IS 3309, IS 4335 and IS 7809 (HDLC of ISO) as well as ITU-T X.25 and Q.92x (LAP-B and LAP-D of 
ITU, respectively.) RLP has been tailored to the special needs of digital radio transmission. RLP provides to its users 
the OSI Data Link Service (IS 8886). 

RLP is intended for use with non-transparent data-transfer. Protocol conversion may be provided for a variety of 
protocol configurations. Those foreseen immediately are: 

- Character-mode protocols using start-stop transmission (IA5); 

- X.25 LAP-B. 

For reasons of better presentation, material about protocol conversion has been placed within those Specifications 
concerned with the relevant Terminal Adapters, i.e. 3G TS 27.002 for the asynchronous case and 3G TS 27.003 for the 
synchronous case. Care must be taken that that material also applies to Interworking Functions; see 3G TS 29.006 and 
29.007. 



Normative references 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

- References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

- For a specific reference, subsequent revisions do not apply. 

- For a non-specific reference, the latest version applies. 

- A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same 
number. 

[1] GSM 0L04: "Digital cellular telecommunication system (Phase 2+); Abbreviations and 

acronyms". 

[2] GSM 04.21: "Digital cellular telecommunication system (Phase 2+); Rate adaption on the Mobile 

Station - Base Station System (MS - BSS) interface". 

[3] GSM 08.04: "Digital cellular telecommunications system (Phase 2+); Base Station System - 

Mobile-services Switching Centre(BSS - MSC) interface Layer 1 specification". 

[4] GSM 08.20: "Digital cellular telecommunications system (Phase 2+); Rate adaption on the Base 

Station System - Mobile-services Switching Centre (BSS - MSC) interface". 

[5] 3GPP TS 25.410: "UTRAN I^ Interface: General Aspects and Principles". 

[6] 3GPP TS 25.411: "UTRAN lu Interface Layer 1". 

[7] 3GPP TS 25.414: "UTRAN lu Interface Data Transport and Transport SignalHng". 

[8] 3GPP TS 25 .4 1 5 : "lu Interface CN-UTRAN User Plane Protocols" . 

[9] 3G TS 27.001 : "3GPP; TSG CN; General on Terminal Adaptation Functions (TAF) for Mobile 

Stations". 

[10] 3G TS 27.002: "3GPP; TSG CN; Terminal Adaptation Functions (TAF) for services using 

asynchronous bearer capabilities". 
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[11] 3G TS 27.003: "3GPP; TSG CN; Terminal Adaptation Functions (TAF) for services using 

synchronous bearer capabilities". 

[12] 3G TS 29.006: "3GPP; TSG CN; Interworking between a Public Land Mobile Network (PLMN) 

and a Packet Switched Public Data Network/Integrated Services Digital Network (PSPDN/ISDN) 
for the support of packet switched data transmission services". 

[13] 3G TS 29.007: "3GPP; TSG CN; General requirements on interworking between the PubHc Land 

Mobile Network (PLMN) and the Integrated Services Digital Network (ISDN) or Public Switched 
Telephone Network (PSTN)". 

[14] ITU-T Recommendation Q.920: "ISDN user-network interface data link layer - General aspects". 

[15] ITU-T Recommendation Q.921: "ISDN user-network interface - data link". 

[16] ITU-T Recommendation Q. 92 Ibis: "Abstract test suites for LAPD conformance tests". 

[17] ITU-T Recommendation Q.922: "ISDN data link layer specification for frame mode bearer 

services". 

[18] ITU-T Recommendation V.42bis: "Data Compression for Data Circuit Terminating Equipment 

(DCE) using Error Correction Procedures". 

[19] ITU-T Recommendation X.25: "Interface between Data Terminal Equipment (DTE) and Data 

Circuit Terminating Equipment (DCE) for terminals operating in Packet Mode and connected to 
Public Data Networks by dedicated Circuit" . 

[20] ISO/IEC Recommendation 4335: "Information technology - Telecommunications and information 

exchange between systems - High level data link control (HDLC) procedures - Elements of 
procedures". 

[21] ISO Recommendation 3309: "Information technology - Telecommunications and information 

exchange between systems - High level data link control (HDLC) procedures - Frame structure". 

[22] ISO Recommendation 7498: "Information processing systems - Open Systems Interconnection - 

Basic Reference Model". 

[23] ISO Recommendation 8885: "Information technology - Telecommunication and information 

exchange between systems - High-level data link control (HDLC) procedures - General purpose 
XID frame information field content and format" . 

[24] ISO Recommendation 8886: "Information technology - Telecommunication and information 

exchange between systems - Data link service definitions for Open Systems interconnection" . 

[25] ISO Recommendation 8509: "Information processing systems - Open Systems Interconnection - 

Service conventions". 

[26] ISO/IEC Recommendation 7809: "Information technology - Telecommunication and information 

exchange between systems - High-level data link control (HDLC) procedures - Classes of 
procedures". 

[27] ISO Recommendation 7776: "Information processing systems - High-level data link control 

procedures - Description of the X.25 LAPB -compatible DTE data link procedures". 

2.1 Definitions and abbreviations 

Abbreviations used in this TS are Hsted in GSM 01.04 [1]. 

For the purposes of this TS, the following definitions apply: 

backwards compatibility: RLP defines several backwards-compatible versions. That means that a newer version can 
interwork with an older one without changing the older one. This is realized by a fall back mechanism during XID 
exchange. 
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command: An instruction represented in the RLP header, causing the receiving RLP entity to execute a specific 
function. 

frame check sequence: A field of redundant information based on a cycHc code, used for error detection. 

I + S frame: An RLP frame that is used for user information transfer, carrying supervisory information piggyback. 

improper frame: An RLP frame having an FCS error or having a header the contents of which is inconsistent with this 
Specification. 

non- transparent: In PLMN data transmission, a configuration where at layer 2, protocol information of the fixed 
network is mapped on RLP elements, and vice versa. 

piggybacking: Means by which one and the same frame can carry both user information and RLP related supervisory 
information. 

response: A reply represented in the RLP-header, by which the sending RLP entity reports back about its status. 

RLP frame: A sequence of contiguous bits, representing an RLP procedural element. 

RLP header: That part of an RLP frame that encodes either a command or a response, located at the beginning of the 
RLP frame. 

S frame: An RLP frame that contains supervisory information in the absence of user information. 

transparent: In PLMN data transmission, a configuration where at layer 2 (and also at the layers above) no protocol 
conversion takes place. 

U frame: An RLP frame that contains unnumbered protocol control information. 

STM: Synchronous Transfer Mode 

ATM: Asynchronous Transfer Mode 



3 Introduction 

Three versions of RLP are defined: 

RLP version 0: single-link basic version; 

- RLP version 1: single-link extended version (e.g. extended by data compression); 

RLP version 2: multi-link version. 

RLP uses one physical link (single-link) or from 1 up to 4 (multi-link) substreams on one or more physical links. 
However, the RLP multi-link version is designed to be able to support up to 8 physical links. If, in the call set-up 
signalling, either end indicates that it cannot support multi-link operation, neither end shall require usage of RLP- 
versions higher than L If the BC negotiation during call set-up results in a possibility for multi-link operation during the 
call, both ends shall require and accept RLP version 2 only. 

If the BC negotiation during call set-up results in "maximum number of traffic channels" = "1 TCH" and UIMI = "not 
required/not allowed" or "up to 1 TCH/F allowed/may be requested", this is interpreted as if at least one end does not 
support multi-link operation, and neither end shall require RLP version higher than 1 . 

RLP makes use of an underlying FEC (Forward Error Correction) mechanism. For RLP to perform adequately it is 
assumed that the basic radio channel together with FEC provides for a block error rate of less than 10 %, where a block 
consists of 240 or 576 bits (Further study on the BLER for 576-bit blocks is needed). Furthermore, it is assumed that in 
case of multi-link RLP the difference of the delay between all physical links is less than timer T4. 

In GSM, RLP frames are sent in strict alignment with the radio transmission. (For details, see GSM 04.21). RLP frames 
are of a fixed size of 240 (TCH/F4.8 and TCH/F9.6 channel codings) or 576 bits (TCH/F14.4, TCH/F28.8 and 
TCH/F43.2 channel codings). Whenever a frame is to be sent, the RLP entity has to provide the necessary protocol 
information to be contained in it. In UMTS, the RLP frame size does not depend on the channel coding, only 576 bit 
frames are used. 
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RLP entities running only in an UMTS environment need only to support the 576 bit frame length. The REMAP 
function is not necessary. RLP entities running in both of the systems have to support the REMAP function. In a 
handover from UMTS to GSM the frame either stays 576 bits long or changes from 576 bits to 240 bits incurring a 
REMAP. In a handover from GSM to UMTS the frame either stays 576 bits long or changes from 240 bits to 576 bits 
incurring a REMAP. 

Provision is made for discontinuous transmission (DTX). 

RLP spans from the Mobile Station (MS) to the interworking function (IWF), located at the nearest Mobile Switching 
Centre (MSC), or beyond. Depending on the exact location of the IWF, handover of the MS may result in link-reset or 
even total loss of the connection. 

The MS shall initiate the RLP link. In addition the MSC/IWF may initiate the RLP link. 

In the terminology of HDLC, RLP is used in a balanced configuration, employing asynchronous operation, i.e. either 
station has the right to set-up, reset, or disconnect a link at any time. Procedural means are provided for to deal with 
contentious situations, should they ever occur. 

RLP is full-duplex in the sense that it allows for information to be transferred in both directions simultaneously. 



Frame structure 



4.1 



Basic frame structure 



In GSM, an RLP-frame has a fixed length of either 240 bits, used when the channel coding is TCH/F4.8 or TCH/F9.6, 
or 576 bits, used when the channel coding is TCH/F14.4, TCH/F28.8 or TCH/F43.2. In UMTS, the RLP-frame has a 
fixed length of 576 bits. 

A frame consists of a header, an information field, and an ECS (frame check sequence) field. The size of the 
components depends on the radio channel type, RLP version and on the RLP frame. As a benefit of using strict 
alignment with underlying radio transmission there is no need for frame delimiters (like flags etc.) in RLP. In 
consequence, there is no "bit- stuffing" necessary in order to achieve code transparency. 

a) 240 bit frame size 



Header 


Information 


ECS 



version and 1 , version 2 (U frames only) 
version 2 (S and I+S frames only) 



16 bit 
24 bit 



200 bit 
192 bit 



24 bit 
24 bit 



b) 576 bit frame size 



Header 


Information 


ECS 



version 0, 1, and version 2 (U frames only) 16 bit 536 bit 

version 2 (S and I+S frames only) 24 bit 528 bit 

Figure 1 : Frame structure 



24 bit 
24 bit 



4.2 



RLP header 



An RLP-header carries one of three types of control information, the first being unnumbered protocol control 
information (U frames), the second being supervisory information (S frames), the third being user information carrying 
supervisory information piggybacked (I + S frames). 
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4.3 Order of transmission 

The header, as defined in clause 5.2, shall be transmitted from left to right. The FCS shall be transmitted commencing 
with the highest order term. The order of bit transmission for the information field is from left to right. 

4.4 Frame check sequence 

The FCS shall be the ones complement of the modulo 2 sum of: 

a) the remainder of : 
For 240 bit frames: 

-j^216 ^-j^23 _^ -j^22 _^ -j^21 _^ ^^0 _^ -^^19 _^ -^^18 + ^^1 + x^^ + x^^ + x^"^ + x^^ + x^^ + x^^ + x^^ + x^ + x^ + x'^ + x^ + x^ + x"^ + 

x^ + x^ + x+ 1) 

For 576 bit frames: 
^552 (^-^23 + ^22 ^ -^21 _^ -^20 + ^19 + ^^^ + x^^ + x^^ + x^^ + x^^ + x^^ + x^^ + x^^ + x^^ + x^ + x^ + x^ + x^ + x^ 

+ X^ + X^ + X^ + X + 1 

divided modulo 2 by the generator polynomial: 

and 

b) the remainder of the division modulo 2 by the generator polynomial: 

-^24 _^ y23 _^ y2l _^ y20 _^ -j^l9 _^ -^^17 _^ -^^16 _^ -^^15 _^ -^^13 + ^^ + ^'^ + ^^ + ^"^ + ^^ + ]^ 

of the product of x^^ by the content of the frame, excluding the FCS field. (The first bit transmitted corresponds 
to the highest order term.) 

Implementation note: As a typical implementation, at the transmitter, the initial content of the register of the device 
computing the remainder of the division is pre-set to all ones and is then modified by division by the generator 
polynomial (as described above) of the header and information field; the ones complement of the resulting remainder is 
transmitted as the 24 bit FCS sequence. 

At the receiver, the initial content of the register of the device computing the remainder is pre-set to all ones. The final 
remainder after multiplication by x^^ and then division (modulo 2) by the generator polynomial: 

-^24 _^ -j^23 _^ -j^21 _^ -j^20 _^ -j^l9 _^ -^^17 _^ -^^16 _^ -^^15 _^ -^^13 + j^^ + j{J + j^5 _^_ ^4 _^_ ^^2 _^_ ^ 
of the serial incoming protected bits and the FCS will be: 
011011011000100100110000 (x23 to x^, resp.) 
in the absence of transmission errors. 



Elements and procedure 



5.1 Modes 

An RLP entity can be in one of two modes: 
- Asynchronous Balanced Mode (ABM) 
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Asynchronous Disconnected Mode (ADM) 

5.1 .1 Asynchronous Balanced Mode (ABM) 

In ABM, which is the data link operational mode, either RLP entity may send commands at any time and may initiate 
response frame transmission without receiving explicit permission to do so from the other RLP-station. In ABM, frames 
shall be used for information field transfer and/or to indicate status changes in the RLP-station. 

5.1 .2 Asynchronous Disconnected Mode (ADM) 

In ADM, which is the data-link non-operational mode, the RLP entity shall be logically disconnected from the data link 
and shall, therefore, neither transmit nor accept numbered information frames. 

The RLP entity shall, however, be permitted to transmit and accept NULL, DM, UI, TEST and XID frames. Either RLP 
entity can issue an SABM command at any time, in order to terminate the ADM state. In that case, entrance of the ABM 
state will be indicated by a UA response from the opposite station. If the opposite station is not able to enter ABM, it 
will indicate this by a DM response. All commands other than those mentioned above and any unsolicited response will 
be ignored in ADM under all circumstances. 

5.2 Header and parameters 

The formats defined for the header are listed in figure 2. 

5.2.1 Generally used bits 

NOTES: C/R = COMMAND/RESPONSE BIT 
P/F = POLL/FINAL BIT 
X = DON'T CARES 



3i 


32 










RR 





1 


REJ 


1 





RN R 


1 


1 


SREJ 



M-1M2M3M4M5 




11100 


SABM 


00110 


UA 


0001 


DISC 


1 1 000 


DM 


11110 


NULL 


00000 


UI 


11101 


XI D 


00111 


TEST 


10001 


REMAP 



Versions and 1: 



NOTES: N(S) 
N(R) 



Bit 4 low order bit 
Bit 1 1 low order bit 



bit 



u 


C/R 


X 


X 


1 


1 


1 


1 


1 


1 


P/F 


Ml 


M2 


M3 1 M4 


M5 1 


X 


s 


C/R 


S1 


S2 





1 


1 


1 


1 


1 


P/F 


M /D\ 


N (R) 


+s 


C/R 


S1 


S2 


M /0\ 


P/F 






M /D\ 




— 


N(S) 






N(R) 



10 



11 



12 



13 



14 



15 16 



Version 2: 
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NOTES: 



bit 1 



S = 

N(S) 
N(R) 
UP 



L2R Status Bit 

Bit 1 low order bit 

Bit 14 low order bit 

UP bit (only if negotiated, 'don't care' otherwise) 



u 


C/R 


X 


X 


1 


1 


1 


1 


1 


1 


P/F 


M1 


M2 


M3 


M4 M5 X 








s 


X 


X 


X 





1 


1 


1 


1 


1 


P/F 


C/R 


S1 


S2 


M/D\ 


X 


UP 


N(R) 


+s 










^(S) 










P/F 


C/R 


S1 


S2 


N(R) 


S 


UP 















10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 



Figure 2: Header formats 



5.2.1.1 



Command/response bit, C/R 



The C/R-bit is used to indicate whether the frame is a command or response frame and whether the P/F-bit is to be 
interpreted as a poll or final bit, resp. For commands, the C/R bit shall be set to "1", for responses it shall be set to "0". 



5.2.1.2 



Poll/Final bit, P/F 



The P/F-bit is used to mark a special instance of command/response exchange. With a command, it is called the P-bit, 
with a response, it is called the F-bit. In any one direction, only one P/F-bit exchange may be outstanding at any time. A 
response with the F-bit set to " 1 " shall always reflect the latest receive status of the RLP entity. 

A P/F-bit exchange always starts with a command frame with the P-bit set to "1", which shall be answered by a 
response frame with the F-bit set to " 1 " at the earliest response opportunity. 

No unsolicited F-bit = "1" is allowed. Such a frame shall be considered "improper" (see subclause 5.3.1). In ABM, the 
use of the P/F-bit with numbered information exchange is only allowed for checkpoint-recovery (see subclause 5.3.3). 

5.2.2 Unnumbered frames, U 

5.2.2.1 Set asynchronous balanced mode SABM (1 1 100) 

The SABM encoding is used as a command only. It is always used with the P-bit set to "1". 

The SABM command is used either to initiate a link for numbered information transfer, i.e. to go from ADM to ABM, 
or to reset a link already established for numbered information transfer. With an SABM command, no information 
transfer is allowed. 

When issuing an SABM, the RLP entity has set to zero its internal variables for sending and receiving numbered 
information. The other RLP entity, on receiving an SABM command, will either confirm it by setting to zero its internal 
variables for sending and receiving numbered information and then issuing an UA (unnumbered acknowledgement) 
response or reject it by sending a DM (disconnected mode) response. In the former case, both entities have entered 
ABM and numbered information transfer may commence. In the latter case, both entities are in ADM. 

When an SABM command is issued, a loss of information may occur. Appropriate action is in the responsibility of the 
layers above. 



5.2.2.2 



Unnumbered Acknowledge. UA (001 10) 



The UA encoding is used as a response only. It is used to positively acknowledge an SABM or DISC command. With 
the UA response, no information transfer is allowed. In version 2, the UA response is sent no sooner than T4 (see 
Section 5.5.6) after the last information frame sent. Information frames received within a period of T4 after reception of 
the SABM are discarded. 



5.2.2.3 



Disconnect, DISC (00010) 



The DISC encoding is used as a command only. It is used to disestablish a link, previously established for numbered 
information transfer, i.e. to terminate ABM and go into ADM. With the DISC command, no information transfer is 
allowed. 
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The other RLP-entity shall answer with a UA response before actioning the DISC command. When a DISC command is 
actioned, loss of information may occur. It is the responsibility of the layers above, to provide for a "graceful" 
disconnect. 



5.2.2.4 



Disconnected Mode, DM (11000) 



The DM encoding is used as a response only. It is used by RLP entity to report that it is in ADM and, as an answer to 
SABM, that it is (possibly temporary) unable to action a mode setting command. With the DM response, no information 
transfer is allowed. 



5.2.2.5 



Unnumbered Information, Ul (00000) 



The information field is to be interpreted as unnumbered information. Unnumbered Information (UI) frames can be sent 
in both ADM and ABM. There is no acknowledgement of receipt of Ul-frames within RLP. 



5.2.2.6 



Exchange Identification, XID (11101) 



The information field is to be interpreted as exchange identification. This frame is used to negotiate and renegotiate 
parameters of RLP and layer 2 Relay function. XID frames can be sent in both ADM and ABM. 

The negotiation procedure is one step i.e. one side will start the process by sending an XID command, offering a certain 
set of parameters from the applicable parameter repertoire (see table 1) the sending entity wants to negotiate proposing 
values within the allowed range. In return, the other side will send an XID response, either confirming these parameter 
values by returning the requested values, or offering higher or lower ones in their place (see table 1 for sense of 
negotiation), except when the indicated RLP version is a lower one where a limited set of those parameters presented in 
the XID command may be answered according to the negotiated version. In RLP versions higher than "0", any 
unrecognisable parameters will be ignored. Default values will apply to those parameters which are not commented 
upon by the responding side (see section 5.4 for default values). This normally will end the negotiation process. XID 
frames are always used with the P/F-bit set to " 1 " . 

Without any prior XID exchange, default values will apply (see section 5.4). A negotiation of data compression 
parameters (see table 1) is only allowed in ADM. In addition, in RLP version 2, negotiation of RLP version N°(see 
table 1) is only allowed in ADM. 

In the case of a collision of XID commands, all XID commands shall be ignored. The MS shall restart the parameter 
negotiation on expiry of Tl, while the Interworking Function shall do so on expiry of twice the value of TL An 
unsuccessful XID exchange shall be repeated on expiry of TL After N2 times of unsuccessful repetition, the link shall 
be disconnected. 

In table 1 a list of parameters is given which constitute the parameter repertoire. In addition, the format of the XID 
information field is given. 

Table 1 : XID parameters 



Parameter Name 


Type 


Length 


Format 

(87654321) 


Units 


Sense of 
Negotiation 


Valid in 
Versions 


RLP version N° 


1 




bbbbbbbb* 


./. 


down 


>0 


IWF to MS window size 


2 




OObbbbbb 


./. 


down 


0..1 


IWF to MS window size 


2 




OObbbbbb 


8 


down 


>2 


MS to IWF window size 


3 




OObbbbbb 


./. 


down 


0..1 


MS to IWF window size 


3 




OObbbbbb 


8 


down 


>2 


Acknowledgement Timer(Tl) 


4 




bbbbbbbb 


10ms 


up 


>0 


Retransmission attempts (N2) 


5 




bbbbbbbb 


./. 


up 


>0 


Reply delay (T2) ** 


6 




bbbbbbbb 


10ms 


up 


>0 


Compression Pj 

Po 

Pi low 


7 


4 


aaaa 

OObb 
cccccccc 
cccccccc 




none 
see [15] 

down 


>1 
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Pl high 
P2 






dddddddd 


./. 


down 




Re-sequencing timer (T4) ** 


8 


1 


bbbbbbbb 


10 ms 


up 


>2 


Optional features 


9 


1 


bbbbbbbb 


./. 


down 


>2 



* NOTE 1: Characters "a", "b", "c" and "d" indicate a bit which is part of the parameter value in question. 
Parameters indicated by "a" are not negotiable. 

** NOTE 2: In case of negotiation of this parameter it may be necessary to negotiate also the other timer values 
(e.g. "Acknowledgement timer" (Tl)). 

The type and length are encoded within one octet, the type field occupying bits 8 to 5 and the length field occupying 
bits 4 to 1; 1 resp. 5 being the least significant bit. The least significant bit shall always be transmitted first. 

A parameter item consists of the type/length-octet followed by the value of that parameter, where the length-indicator 
gives the number of octets the value actually occupies. Such parameter items may be arranged in arbitrary order, with 
the exception of the RLP version number, which shall be sent first in RLP versions higher than "0". The parameter 
items must begin in the first octet of the XID-information field and follow on contiguously. The parameter list is 
delimited by parameter type zero. 



5.2.2.7 



Test, TEST (00111) 



The information field of that frame is to be interpreted as test information. Test frames can be sent in both ADM and 
ABM. A test sequence is always initiated by sending a TEST command in one direction and completed by sending a 
TEST response in the other direction. 



5.2.2.8 



Null information, NULL (11 110) 



In ADM, null-frames shall be sent each time there is a send opportunity but no UI, TEST or XID frame is awaiting 
transmission. 

In ABM, null-frames shall be sent in reset state if there is a send opportunity and no unnumbered frames are to be sent. 

The information field is to be interpreted as null information i.e. the information field is not used and its contents may 
be arbitrary. 



5.2.2.9 



REMAP (10001) 



A REMAP-exchange can only take place in ABM following a change of channel coding. REMAP frames are always 
used with the P/F-bit set to "0". The exchange is started by the mobile-end which sends a REMAP command U-frame in 
the information field of which the RLP-entity indicates the N(R) of the frame - according to the 'old' frame format - 
from which the network-end should resend the information mapped into a frame format corresponding to the new 
channel coding. The mobile-end sends a REMAP-frame on every sending opportunity until a responding REMAP- 
frame is received from the network-end. The network-end answers by sending a REMAP U-frame with the C/R-bit set 
to 'Response'. In the information-field the network-end indicates the N(R)-number of the frame from which the mobile- 
end should remap the information into the new frame format. The network-end responds to all REMAP-commands it 
receives as long as it is in the REMAP synchronisation state. The network sends a numbered S frame with poll bit P=l 
or an I+S frame after the first REMAP frame to the mobile station to compel it to acknowledge the end of the REMAP 
condition. This frame is guarded by Tl. Upon reception of an I+S frame or an S frame with the final bit F=l from the 
MS, the IWF exists the REMAP synchronisation state. Any REMAP-acknowledgement that may arrive at the mobile- 
end after one of them has been received is discarded by the mobile-end. The RLP shall supervise the synchronisation 
state by a timer with the value of N2*T1. If the network-end does not receive an appropriate U-frame within N2*T1, it 
enters ADM. If the mobile-end does not receive a response within N2xTl measured from the transmission of the first 
command, it enters ADM. 

In addition to the N(R) -information the REMAP-frame information field can include any XID-parameters that should 
be renegotiated because of the change of channel coding. The procedures concerning these XID-parameters are as 
defined in section 5.2.2.6 (Exchange Identification) except that the mobile-end always starts the negotiation. Also the 
mapping of the parameters is as defined in section 5.2.2.6 (Exchange Identification) except that the first two octets in 
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the REMAP information field are occupied by the N(R)-number (The LSB is transmitted first). The information field 
shall always include parameter type zero, which delimits the XID-parameter list. 

After the change of channel coding, default values according to the new channel coding apply until new values have 
been negotiated by the REMAP or XID procedure. Default values according to the new channel coding also apply for 
those XID parameters that are not included in the REMAP information field. Values for XID parameters whose 
negotiation is only allowed in ADM remain valid after change of channel coding. 



Header 16 bits 


N(R) 6 bits xxxxxxxxxx XID parameters 


00000000 


xxxxxx 


FCS 24 bits 




Information field either 200 or 536 bits x= don't care 








a.) version and 1 










Header 16 bits 


N(R) 9 bits xxxxxxx XID parameters 


00000000 


xxxxxx 


FCS 24 bits 



Information field either 200 or 536 bits x= don't care 



b.) version 2 



Figure 3: REMAP U-frame format 



5.2.3 Supervisory frames, S, and numbered information transfer and 
supervisory frames combined, l+S 

In ABM, there are cases where there is no user information pending transmission. In consequence, supervisory (S) 
frames alone must be conveyed. In such cases, the information field is to be interpreted as null information, i.e. the 
information field is not used and may be of arbitrary contents. 

For reasons of optimization in the special situation of digital radio transmission, numbered information transfer frames 
carry also supervisory type information ("piggy-backing"). Numbered information can be exchanged only in ABM. 

NOTE: The extent to which piggy-backing is used by the sending RLP entity is optional. An RLP entity receiving 
any of allowed piggy-backed formats, however, shall take the appropriate actions. Implementers should 
be aware that not using the full capability of piggy-backing could, in certain circumstances, result in a less 
than optimal performance. 



5.2.3.1 



Numbering 



Each I frame is sequentially numbered and may have the value through M-1, where M is the modulus. The modulus 
M is 62 (single-Hnk) or 496 (multi-Hnk). 



5.2.3.2 



Send Sequence number, N(S) 



The send sequence number contains the number of the I frame. With the exception of SREJ conditions, information 
frames are transmitted in numerical order of their N(S). If multiple substreams are used, the frames may arrive at the 
receiver in another order. Normal information transfer is halted, when the number of outstanding, unacknowledged 
frames is equal to the currently established window size (see section 5.4). 



5.2.3.3 



Receive sequence number, N(R) 



The N(R) field is used in ABM to designate the next information frame to be sent by the other RLP entity and to 
confirm that all frames up to and including N(R) - 1 have been received properly. As an exception to this, in the case of 
SREJ (selective reject), N(R) designates the information frame that is selectively rejected and thus requested for 
retransmission. In this case, no previously received frames are confirmed. 



5.2.3.4 



L2R Status bit 



The L2R status bit set to ,,1" indicates that the L2R PDU transported in the information field of the RLP PDU contains 
at least a status octet. Otherwise, the L2R PDU contains only user data. The bit is only used for RLP-version 2. 
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5.2.3.5 Receive ready, RR (00) 

The RR encoding can be used either as command or response. In ABM, it is used by an RLP entity to confirm all 
information frames up to and including N(R)-1. In doing so, the RLP-station allows the other station to transmit up to k 
additional information frames, counting from N(R) onwards. The issue of an RR command/response clears any previous 
busy condition in that direction. 

5.2.3.6 Reject, REJ (01) 

The REJ encoding can be used either as command or response. It is used by an RLP entity to indicate that in numbered 
information transfer one or more out-of sequence frames have been received. Frames up to and including N(R)-1 have 
been received correctly, frames N(R) and following are requested to be retransmitted. Following retransmission of those 
frames, further frames awaiting initial transmission may be sent. With respect to each direction of transmission, only 
one REJ condition may exist at any given time. 



ETSI 



(3G TS 24.022 version 3.2.0 Release 1 999) 1 7 eTSI TS 1 24 022 V3.2.0 (2000-01 ) 

A RE J condition is cleared: 

on receipt of the frame numbered N(R); 

- on time-out; 

- or on reset (SABM). 

An REJ shall be sent at the earliest opportunity. On time-out, REJ frames shall not be repeated. An RLP-entity receiving 
an REJ frame with the same N(R), which has already been the starting frame of a retransmission sequence due to P/F- 
bit checkpointing, shall inhibit the retransmission due to that particular REJ frame. 

5.2.3.7 Receive not ready, RNR (10) 

The RNR encoding can be used either as command or response. It is used by an RLP entity to indicate that it is 
temporarily not ready to receive numbered information frames. In that case, the RLP entity is said to be in the busy 
condition. All frames up to and including N(R)-1 shall be considered acknowledged. Subsequent frames, if any, shall 
not be considered confirmed. The acceptance status of those is a matter of further status exchange. 

5.2.3.8 Selective reject, SREJ (1 1 ) 

The SREJ encoding can be used either as command or response. The SREJ command/response is used to request 
retransmission of a single frame, thus, under certain circumstances, providing for more efficient error recovery than by 
REJ. No acknowledgement of received I frames is indicated by an SREJ frame, thus allowing an RLP entity to transmit 
one or more SREJ frames with a different N(R) before earlier SREJ conditions have been cleared. 

An SREJ condition shall be cleared: 

- on receipt of an information frame with N(S) equal N(R) of the SREJ; 

- on time out; 

- on reset (SABM). 

No SREJ shall be issued during a pending REJ condition. For each frame, only one SREJ condition may exist at any 
time. 

SREJ frames shall be sent at the earliest possibility. On time-out, SREJ frames may be repeated. 

NOTE: Sending SREJ commands/responses is not mandatory. 

5.2.3.9 Upgrading Proposal bit, UP bit 

In version 2, the UP bit in the S and I+S frame headers may be used by the IWF to indicate to the MS that a service 
level upgrading will increase the throughput, and is used in accordance with 3G TS 27.001 and 29.007. The usage of the 
UP bit is negotiated by XID exchange. 

5.3 Error Recovery 

5.3.1 Improper frames 

Frames containing an FCS error or having a control field the contents of which is not implemented or inconsistent with 
those defined in this Specification are called improper frames. Improper frames shall be ignored, i.e. the receiving RLP 
station shall not make any use of their contents. 

5.3.2 N(S) sequence error 

In numbered information transfer, any information frame with an N(S) out of the normal sequence shall lead to an N(S) 
sequence error condition, unless that frame is requested for retransmission by an SREJ, sent at an earlier time. In case 
multiple substreams make up a connection when the multi-link version is used the received frames must be re- 
sequenced. For that a timer T4 defines a re-sequencing period (see section 5.4) during which frames may be out-of- 
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order. An N(S) sequence error condition only occurs if the N(S) arrives after the expiry of T4. There are three 
mechanisms to deal with N(S) sequence errors: 

RE J recovery; 

- SREJ recovery; 

- P/F-bit recovery (checkpointing); 

the first two being the responsibility of the receiving station, the last being the responsibility of the sending station. 
There are no strict rules as to whether REJ or SREJ recovery shall be applied, however, if a station decides to initiate 
REJ or SREJ recovery, it shall do so at the earliest opportunity. The information part of out-of sequence frames shall be 
discarded, unless the receiving station intends to initiate SREJ recovery. 

5.3.3 N(R) error 

Any confirming N(R) that is not in the range of the window size shall be ignored. 

5.3.4 Time-out and checkpointing 

All frames requiring a response or acknowledgement shall be guarded by time-out (timer Tl). In detail, those frames 
are: 

- SABM; 

- DISC; 

- REJ; 

- SREJ; 

numbered information frames (see note); 

- any frame with the P-bit set to "1" in ABM, i.e. checkpointing. 

NOTE: Tl started, or restarted if already running, on the transmission of every numbered information frame. 

5.3.4.1 Treatment of errors during link establishment, link reset and link disconnect 

An SABM, which is not answered by either UA or DM within the timer period, shall be repeated up to N2 times. 

A DISC, which is not answered by UA within the timer period, shall be repeated up to N2 times. 

If the SABM or DISC, respectively, is finally unanswered, the RLP station will go into ADM in any case. For this 
reason, it is the responsibility of the management of any RLP entity to put the RLP entity into ADM, should there be an 
indication of a permanent outage, i.e. a loss of connectivity longer than N2 times the timer value. 

5.3.4.2 Treatment of errors during numbered information transfer 

The last frame of a sequence of numbered information frames shall also be guarded by time-out. If neither a positive 
acknowledgement nor a REJ is received, the RLP entity will start checkpoint recovery, i.e. the station will send a frame 
with the P-bit set to "1", requesting the latest status information from the other entity, indicated by the F-bit set to "1". 
In that case, status information is carried either by RR or RNR responses and all frames currently held by the 
responding RLP entity which are not delivered because of missing frames shall be discarded. A P-bit set to " 1 " shall 
only be sent with a Supervisory Frame. 

Awaiting the latest status information from the other RLP entity, the sending entity does not react on REJ and SREJ 
frames received during this time. If such status information is received, retransmission from N(R) onwards will be 
performed if appropriate. However, no frame sequence starting with a given N(R) shall be retransmitted more than N2 
times. If there is a frame sequence that cannot be transmitted successfully after N2 repetitions, the RLP link shall be 
reset or disconnected. 
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If no status information is received during the time-out period, this request will be repeated up to N2 times. If still there 
is no valid status reported back, the RLP link shall be reset or disconnected. 

5.3.5 Contentious situations 

Due to the asynchronous procedure, various contentious situations may arise. A contention of SABMs shall result into 
both entities be set into ABM or be reset. A contention of DISC'S shall result into both entities be disconnected. A 
contention of SABM and DISC shall result into both entities be disconnected. 

5.4 Transitions between 240 bit and 576 bit frame lengths 

The RLP has to change the supported frame length due to transitions between different channel codings. The RLP 
entities have to be re-synchronised after a change of the channel coding. 

Any change of the channel coding is indicated to the RLP- entity by an external event. The RLP-entity at the mobile- 
end enters the synchronisation state when it receives a relevant Radio Resource Management message, and it starts 
sending the REMAP-messages at the earliest possible time. The RLP-entity at the network-end enters the 
synchronisation state when the network-end detects Layer 1 synchronisation after a change of channel coding. The 
change of channel coding is eventually confirmed by an outband signalling message. 

On entering the synchronisation state timers are halted and zeroed, and the TX- and RX-windows are frozen. When the 
RLP entity enters the synchronisation state it clears all SREJ or REJ conditions, discards all out-of-sequence frames 
received and clears all previous re-transmission requests received by any SREJ. 

After this the mobile-end starts a REMAP-exchange (Section 5.2.2.9). When an RLP-entity receives a REMAP-frame, 
it moves the user information contained by the frames to be remapped from the TX-window to a transition buffer 
between the RLP- and L2R-entities. The L2R uses the information in this buffer before mapping new data into the 
PDUs. The network-end regards the REMAP-procedure as completed when it has received an I+S-frame, an S-frame or 
an SABM U-frame from the mobile-end, whereas the mobile-end leaves the synchronisation state after receiving a 
responding REMAP-frame or an SABM U-frame. The data in the transition buffer at the network-end must not be 
deleted before an I+S-, or an S-frame is received from the mobile-end. 

Supervisory or Information transfer frames or XID U frames are discarded by the receiving entity while in REMAP 
synchronisation state. If the RLP entity receives another U-frame, it reacts according to the defined procedures. That is, 
if the frame is an SABM frame it performs a reset procedure and leaves the synchronisation state. If the frame is NULL, 
UI or TEST frame, RLP performs the defined procedure and remains in the synchronisation state. In the case of a DISC 
frame RLP terminates ABM and goes into ADM. 

After the REMAP-procedure is completed, the RLP-entities leave the synchronisation state and normal operation is 
resumed. On resuming the normal operation, the TX- and RX- windows are emptied. The N(S)-numbering resumes 
from the value indicated in the REMAP-message by the N(R)-number. 

Abortion of the transition or another transition taking place during the REMAP-procedure restarts the REMAP- 
procedure in order to resume operation using the channel coding corresponding to the latest transition. 
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5.5 List of system parameters 



The system parameters are as follows: 



Table 2: RLP parameter values 



Name 


Range of values 


Default value 


Recommended value 


Version N° 


0-2 





2 


kMS^IWF 
(forN° = 0/l) 


0-61 


61 


61 


kMS^IWF 

(forN° = 2) 


- kmax (note 3) 


480 


240 (note 2) 


k IWF ^ MS 

(forN° = 0/l) 


0-61 


61 


61 


k IWF ^ MS 

(forN° = 2) 


- kmax (note 3) 


480 


240 (note 2) 


Tl (note 1) 


> 420 ms (version2) 

> 380 ms 

> 440 ms 

> 600 ms 


520 ms (fullrate on 14.5, 29.0 or 
43.5 kbit/s) 

480 ms (fullrate on 12 kbit/s) 
540 ms (fullrate on 6 kbit/s) 
780 ms (halfrate) 


520 ms (fullrate on 14.5, 29.0 or 
43.5 kbit/s) 

480 ms (fullrate on 12 kbit/s) 
540 ms (fullrate on 6 kbit/s) 
780 ms (halfrate) 


T2(notel) 




< 80 ms (fullrate on 14.5, 29.0 or 
43.5 kbit/s) 

< 80 ms (fulrate on 12 kbit/s) 

< 80 ms (fullrate on 6 kbit/s) 

< 80 ms (halfrate) 


< 80 ms (fullrate on 14.5, 29.0 
or 43.5 kbit/s) 

< 80 ms (fullrate on 12 kbit/s) 

< 80 ms (fullrate on 6 kbit/s) 

< 80 ms (halfrate) 


N2 


>0 


6 


6 


Pt 











Po 


0-3 





3 


Pi 


512-65535 


512 


2048 


P2 


6-250 


6 


20 


T4 (note 1) 


>25ms 


30 ms 

50 ms (fullrate on 14.5, 29.0 or 

43.5 kbit/s) 


30 ms 

50 ms (fullrate on 14.5, 29.0 or 

43.5 kbit/s) 


Optional feature, 
Up signalling 


0-1 





1 



NOTE 1 : The timer values shall fulfil the formula: 

Tl > T2 + T4 + (2 * transmission delay) for multi-link operation 

Tl > T2 + (2 * transmission delay) for single link operation 

For GSM the values apply according to indicated channel types, for UMTS the values apply according to 

"fullrate on 14.5". 

NOTE 2: This value is recommended in the case of 4 physical links. 

NOTE 3: The maximum window size shall fulfil the formula 

kmax < 496 -n*(l+T4/20 ms), where n denotes the number of channels. 
Any value k within the given range may be chosen. 
However, to avoid transmission delay the value k should be 
k > n * (2 * transmission delay) / 20 ms. 



5.5.1 



RLP Version N' 



The current version of RLP is "2". "0" is the default value for the version N°. RLP-versions are backwards compatible. 
It is assumed that future versions of RLP will be backwards-compatible with former ones. Backwards-compatible refers 
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to the signalling, i.e. the handling of the parameters in the XID frame. The parameters are defined as specified by the 
RLP version with the lower number. 

5.5.2 Maximum number of outstanding I frames k (Window size) 

The window size is the maximum number (k) of sequentially numbered I frames that may be outstanding (i.e. 
unacknowledged) at any given time. It shall be agreed for a period of time. 

In case of a single-link version the value can never exceed 61. In the case of a multi-link version it is necessary to use a 
window size that is less than the sequence number space to avoid misinterpretations of the confirming N(R). Therefore, 
a guard section is defined and the value k must not exceed the value k^ax defined in table 2. On mutual agreement 
between the communication parties, a smaller window size may be established. For the support of 4 physical links, a 
value of 240 is recommended. 

5.5.3 Timer T1 

The period of Timer Tl is regarded to start at the beginning of the transmission of the relevant frame. 

The negotiation (or default) value is defined to be the earliest instant to enter recovery. 

The period of Timer Tl at the end of which retransmission of a frame may be initiated according to the procedures 
described in 5.3 above, is a system parameter agreed for a period of time. 

The proper operation of the procedure requires that Timer Tl be greater than the maximum time between transmission 
of frames (S ABM, DM, DISC, I or supervisory commands) and the reception of the corresponding frame returned as a 
response to this frame (UA, DM or acknowledging frame). Therefore, the RLP entity should not delay the response or 
acknowledging frame returned to the above frame by more than a value T2. T2 is a system parameter, which is less than 
Tl. Tl is influenced by the value of T4 and shall fulfil the formula in table 2. 

5.5.4 Maximum number of retransmissions N2 

The value of the maximum number of retransmissions N2 of a frame following the running out of Timer Tl is a system 
parameter agreed for a period of time. 

5.5.5 Data Compression Parameters 

If the Layer 2 Relay function supports a data compression function and its use is desired the needed data compression 
parameters have to be negotiated. The parameter Pj is not negotiable. In case of V.42 bis the parameters Pq, P^ and P2 
have to be negotiated. The parameters are defined as follows: 

- Fj\ Type of data compression 

V.42 bis 

other values are reserved 

- Pq: V.42bis data compression request 

compress in neither direction 

1 compress in initiator-responder direction only 

2 compress in responder-initiator direction only 

3 compress in both directions 

- P^ : V.42bis number of possible codewords in the algorithm 

- P2: V.42bis maximum encodable data string length 

The initiator is the sender of XID command, the responder is the sender of XID response. 
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5.5.6 Re-sequencing period (Timer T4) 

In the case of a multi-link version frames may be received out of sequence due to different transmission delays. The 
period of timer T4 guards the re-sequencing period. During this time frames may be out of sequence. 

T4 is a system parameter agreed for a period of time. The proper operation of the procedure requires that the timer T4 
shall be greater than the re- sequencing period and it shall fullfil the formula in table 2. A change of the timer T4 has 
impact on the usable maximum window size as defined in table 2. 

5.5.7 Optional features 

The format of the optional features parameters is an octet where each bit position represents an optional feature that can 
be negotiated. The optional features are: 



Bit position 


Optional feature name 


1 


Up signalling 


2 


(Not yet assigned) 


3 


(Not yet assigned) 


4 


(Not yet assigned) 


5 


(Not yet assigned) 


6 


(Not yet assigned) 


7 


(Not yet assigned) 


8 


(Not yet assigned) 



The 'Optional Features' parameter is negotiated bitwise in the downward sense, meaning that the value of bit / in the 
XID response shall be less or equal to the value of bit / in the XID command. 

Up signalling: If the negotiated value of the 'Up signalling' feature is 1, then the UP bit in the S and I+S frame header 
is used for indicating an upgrading proposal to the MS, otherwise the UP bit is ignored (don't care). This optional 
feature is only applicable for GSM. 

5.6 Support for discontinuous transmission (DTX) 

In both ADM and ABM, whenever the RLP entity has no numbered or unnumbered supervisory commands/responses 
and no information transfer frames pending transmission, the RLP entity shall indicate to the lower layer that the DTX 
function may be invoked. 

5.6.1 In case of GSM 

Protocol of lower layer conforms to GSM 08.04, 08.20 and 04.21. GSM specification assumes STM for lower layer 
protocol. Even if there is no data to be sent, some transmission is needed on STM. RLP acts as follows in case of DTX. 

In case DTX is invoked, in ADM a NULL-frame will be sent, and in ABM a RR or RNR S -frame will be sent. 

5.6.2 In case of UMTS 

Protocol of lower layer conforms to 3GPP TS 25.410, 25.411, 25.414 and 25.415. UMTS specification assumes ATM 
for lower layer protocol. When there is no data to be sent, no transmission is available on ATM. In consideration of 
transmission efficiency, no transmission is suitable. RLP acts as follows in case of DTX. 

In case DTX is invoked, in ADM and ABM no frame will be sent. 
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6.1 



Service definitions 



Introduction 



This chapter defines the service provided by the RLP-sublayer to the L2R-sublayer at the boundary between the RLP- 
sublayer and the L2R-sublayer. 

The relationships between RLP-sublayer, L2R-sublayer and RLP-protocol are shown in figure 4. 



RLP 

< > 



L2RSL 



RLPSL 



user 



RLP Service 



provider 



Figure 4: Basic relationship between RLP and L2R 

The RLP service is defined in terms of: 

- the primitive actions and events of the service; 

- the parameters associated with each primitive action and event; 

- the inter-relationship between, and the valid sequence of, these actions and events. 

6.2 Conventions 

For the description of the Data Link Service, the following conventions are used with time-sequence diagrams: 



RLP-REQUEST 



RLP-CONFIRM 



RLP-INDICATION^ 
RLP-RESPONSE 



Figure 5: Confirmed service witli acknowledgement 



RLP-REQUEST 



RLP-INDICATIO 



^ 



Figure 6: Unconfirmed service 



In time-sequence diagrams, time moves from top to bottom. Arrows indicate the flow of information. Such flow of 
information may be subject to implicit flow-control. Skewed lines indicate a logical relationship between arrows. For 
clarity, the absence of such a relation may be marked by the symbol "--" (tilde). 

6.3 Queue model 

Between the two endpoints of an RLP-connection, there exists a flow control function. As a means of specifying this 
flow control feature and its relationship with other capabilities of the RLP, the following queue model is provided. 
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Service user 
A 



Service user 
B 



Access point 




Access point 






Oi loi lOQ from A tn R 






/- 


\..^..^^ x.^ r> 4.-^ A 






UUtfUtfb II UNI D lU M 

Service provider 







Figure 7: Queue Model 

The following objects may be placed in a queue by a service user: 

a) connect; 

b) connection-mode data (numbered information); 

c) reset; 

d) disconnect. 

The following objects may be placed in a queue by a service provider: 

a) reset; 

b) synchronization mark; 

c) disconnect. 

NOTE: Other possible objects (i.e. unnumbered information, identification, test) are irrelevant (-) to the queue 
model and for reasons of simplicity are not shown. 



Following 
Preceding 


Connect 


Data 


Reset 


Sync Mark 


Disconnect 


Connect 


NA 


— 




NA 


DES 


Data 


NA 


— 


DES 


NA 


DES 


Reset 


NA 


— 


DES 


— 


DES 


Synchronization Mark 


NA 


— 


DES 


NA 


DES 


Disconnect 


NA 


NA 


NA 


NA 


DES 



Legend: 

NA : Not applicable 

~ : not destructive, not able to advance ahead of the preceding object 

DES : Destructive to the preceding object 
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6.4 List of Primitives 

Link establishment 

RLP-CONNECT-REQUEST 

RLP-CONNECT-INDICATION 

RLP-CONNECT-RESPONSE (-NEG) 

RLP-CONNECT-CONFIRM (-NEG) 
Normal Data Transfer 

RLP-DATA-REQUEST (S, INF) 

RLP-DATA-INDICATION (S, INF) 

NOTE: The parameter S (L2R status bit) is only relevant for RLP- version 2. 
Reset 

RLP-RESET-REQUEST 

RLP-RESET-INDICATION 

RLP-RESET-RESPONSE 

RLP-RESET-CONFIRM 
Release 

RLP-DISCONNECT-REQUEST 

RLP-DISCONNECT-INDICATION 
Miscellaneous 

unnumbered information 

RLP-UNITDATA-REQUEST (INF) 

RLP-UNITDATA-INDICATION (INF) 
Exchange Identification 

RLP-XIDDATA-REQUEST (INF) 

RLP-XIDDATA-INDICATION (INF) 
Test 

RLP-TESTDATA-REQUEST (INF) 

RLP-TESTDATA-CONFIRM (-NEG) (INF) 
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6.5 Possible RLP time sequence diagrams 



a) Connection establishment (without collision) 



RLP-CONNECT REQ 



^ 



LP-CONNECTCONF 



b) Connection establishment (with collision) 
RLP-CONNECT REQ^ 



4 



LP-CONNECTCONF 



c) User invoked release (without collision) 



RLP-DISCONNECT RE 



^ 



d) Collision of user invoked releases 
RLP-DISCONNECT REQ 



e) Simultaneous user and provider invoked release 



RLP-DISCONNECT REO 



f) Provider invoked release 

RLP-DISCONNECT IND 



RLP- 



g) Provider rejection of establishment 



RLP-CONNECT REQ 


RLP-CONNECT 
^ CONF-NEG 


V 





RLP-CONNECT 



^ 



RLP-CONNECT RESP 




RLP-CONNECT REQ 



RLP-CONNECT CONF 



QNF 



RLP-DISCONNECT LND 



mp 




RLP-DISCONNECT REQ 




RLP-DISCONNECT I 



NJ 




RLP-DISCONNECT I 



NJ 
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h) Normal data transfer 

RLP-DATA REQ>^ 

I) User invoked reset 

RLP-RESET REQ 



RLP-RESET CONF 



j) Collision of user invoked resets 

RLP-RESET REQ 



RLP-RESET IND 



k) provider invoked reset 

RLP-RESET IND 



RLP-RESET RESP 



^ 



RLP-DATA IND 




RLP-RESET IND 



RLP-RESET RESP 




^ 



LP-RESET REQ 



RLP-RESET IND, 




RLP-RESET IND 



RLP-RESET RESP 



1) simultaneous user and provider invoked reset 
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RLP-RESET REQ 



RLP-RESET IND 



RLP-DISCONNECT 




RLP-DATA-REQUEST 
or INDICATION 

Figure 8: State transition diagram for sequence of RLP connection-mode service primitives 
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Annex A (informative): 
RLP SDL Diagrams 

This annex describes a model implementation of an RLP entity for RLP version "0". 

The description should help to clarify this Specification, the RLP service and protocol definition. 

However, it is not intended to restrict any implementation of an RLP entity in any way, on condition the implementation 
shows the correct behaviour at the RLP protocol level. 

The model implementation consists of three processes. Process "SEND_PDU" adds the CRC to a given PDU and hands 
it to the lower layer entity for transmission. Process "RECEIVE_PDU" gets a received PDU block, checks the value of 
the CRC and the bits of the PDU header. If the CRC has the right value and if the header is syntactically correct, the 
receipt event is signalled to the "RLP_KERNEL" process, which is the protocol handling automaton. 

Each process is described as an extended finite state machine (using SDL-Diagrams). 

Each state of the automaton is described by a (main-) state number and a corresponding (main-) state name. The state 
may further be distinguished by the value of other state variables. This scheme is used because not every state variable 
needs to be defined in every state. The states are defined in chapter A.L 

The RLP machine reacts on events, which may be classified as: 

lower layer interface events; 

- upper layer interface events; and 

- station management or internal events. 

The events of the RLP-Kemel are described in section A.2. 



A.1 List of RLP entity states 
A. 1.1 (main) states 



state number 


state symbol 


state name 





SO 


ADM and Detached 


1 


S1 


ADM and Attached 


2 


S2 


Pending Connect Request 


3 


S3 


Pending Connect Indication 


4 


S4 


ABM and Connection Established 


5 


S5 


Disconnect Initiated 


6 


S6 


Pending Reset Request 


7 


S7 


Pending Reset Indication 



A. 1.2 state variables 

The main states are further distinguished by the values of the state variables. However, not every state variable is used 
(evaluated/ defined) in every state. 

First some constants need to be defined: 

M = 62 number of different sequence numbers (modulus) 

Nmin = smallest sequence number 

Nmax = 61 largest sequence number (= M - 1) 

N2 = 6maximum number of retransmissions 
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variable name variable type and range 



semantic 



Ackn_FBit 


(0,1) 


Ackn_State 


(idle, send) 


C 


(0,1) 


Data 


char[25] 


DISC_Count 


(0, 1,..., N2) 


DISC_PBit 


(0,1) 


DISC_State 


(idle, send, wait) 



DM_FBit 


(0,1) 


DM_State 


(idle, send) 


DTX_SF 


(N, RR, RNR) 


DTX_VR 


(0, 1,.., Nmax) 


F 


(0,1) 


NR 


(0, 1,..., Nmax) 


NS 


(0, 1,..., Nmax) 


P 


(0,1) 


P_F 


(0,1) 


PolLCount 


(0, 1,...,N2) 


PolLState 


(idle, send, wait) 



Poll_xchg 



(idle, wait) 



R[M] 


record array 


R[n].Data 


char[25] 


R[n].State 


(idle, rcvd, ackn, srej, wait) 



Value of the F-Bit used in the next acknowledging PDU. 

Ackn_State = send means, an acknowledging PDU (Supervisory 
or Data) has to be sent. 

to store the C/R-Bit value of a received S- or l-frames 

to store temporarily the information part (user data) of a received 
l-frame. 

to count the transmissions of DISC. 

The value of the P-bit in the next DISC command PDU. 

if (DISC_State = send) the DISC command PDU has to be sent at 

the next possible opportunity. 

if (DISC_State = wait) the RLP entity waits for the corresponding 

response. 

Value of the F-Bit used in the next DM response PDU. 

if (DM_State = send) the PDU DM has to be sent. 

to store the last Supervisory frame for DTX (only RR or RNR can 
be suppressed) 

to store the last transmitted value of VR (used to decide the DTX 
condition) 

to store temporarily the F-bit of a received response PDU. 

to store temporarily the receive sequence number of a received S- 
or l-frame 

to store temporarily the send sequence number of a received I- 
frame 

to store temporarily the P-bit of a received command PDU 

to store temporarily the P- or F-bit of received command or 
response PDUs 

to count the transmissions of poll requests 

(PolLState = send) means, a supervisory PDU with P-bit set to 
one has to be sent 

(PolLState = wait) means, the RLP entity waits for the response 
with F-bit set to one 

(Poll_xchg = idle) means, sending of a frame with P-bit set is 

allowed 

(Poll_xchg = wait) means, an acknowledgement of a previous P- 

bit is outstanding 

Receiver slots (M slots, numbered to M-1) 

to store user information 

(R[n]. State = rcvd) means, data has been received (with sequence 

number n). 

(R[n]. State = ackn) means, data has been received and 

acknowledged 

(R[n]. State = srej) means, the retransmission of data has to be 

requested using srej(n). 

(R[n]. State = wait) means, the entity waits for the requested 

retransmitted data 
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REJ_State 


(idle, send, wait) 


returncode 


Integer 


RRReady 


Boolean 


SABM_Count 


(0, 1,..., N2) 


SABM_State 


(idle, send, wait) 


S[M] 


record array 


S[n].Data 


char[25] 


S[n].State 


(idle, send, wait) 


SF 


(RR, RNR, REJ, SREJ) 


T 


Timer 


TEST_Count 


(0,1, ...,N2) 


TEST_C_Data 


char [25] 


TEST_C_PBit 


(0,1) 


TEST_C_State 


(idle, send, wait) 


TEST_R_Data 


char[25] 


TEST_R_FBit 


(0,1) 


TEST_R_State 


(idle, send) 


T_RCVR 


Timer 


T_RCVS(n) 


Timer 


T_TEST 


Timer 


T_XID 


Timer 


UA_FBit 


(0,1) 


UA_State 


(idle, send) 


ULData 


char[25] 


ULPBit 


(0,1) 


ULState 


(idle, send) 


VA 


(0, 1,...,Nmax) 


VD 


(0, 1, ..., Nmax) 


VR 


(0, 1, ..., Nmax) 


VS 


(0, 1, ..., Nmax) 



The REJ_State is send if and only if a REJ PDU has to be sent 

used in procedures to report a result 

Remote Receiver Ready 

to count the transmissions of SABM 

if (.._State = send) the SABM PDU has to be sent 

if (.._State = wait) the RLP entity waits for the UA response 

Sender Slots (M slots, numbered to M-1) 

user information to be sent 

(S[n]. State = send) means, data has to be sent 
(with sequence# n). 

to store the last superv. PDU type 

used by the data sender if waiting for l-frame acknowledgements 
or F-bits 

to count the transmissions of TEST 

data to be sent in the next TEST command PDU 

value of the P-Bit used in the next TEST command PDU 

if (.._State = send) the TEST command PDU has to be sent 
if (.._State = wait) the RLP entity waits for the next TEST 
response 

data to be sent in the next TEST response PDU 

value of the P-Bit used in the next TEST response PDU 

if (.._State = send) the TEST response PDU has to be sent 

used by the receiver to timeout a REJ condition 

used by the receiver to timeout a SREJ condition for Slot n 

used by the sender of a TEST frame if waiting for a TEST 
response 

used by the sender of a XID frame if waiting for the XID response 

value of the F-Bit used in the next UA response 

if (UA_State = send) an UA PDU has to be sent 

data to be sent in the next Ul PDU 

value of the P-Bit used in the next Ul PDU 

if (ULState = send) a Ul PDU has to be sent 

frame sequence number of oldest not yet acknowledged 

l-frame 

(if VA = VS then there are no unacknowledged frames) 

slot number used in the next Data_Req 

receiver sequence number (the next received l-frame is expected 
to carry this sequence number) 

sender sequence number (under normal operating conditions the 
next l-frame is assigned this number) 
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XID_Count (0, 1,...,N2) 

XID_C_Data char [25] 

XID_C_PBit (0,1) 

XID_C_State (idle, send, wait) 



XID_R_FBit 
XI D R State 



(0,1) 
(idle, send) 



to count the transmissions of XID commands 

data to be sent in the next XID command PDU 

value of the P-Bit used in the next XID command PDU 

if (.._State = send) the XID command PDU has to be sent 

if (.._State = wait) the RLP entity waits for the next XID response 

value of the P-Bit used in the next XID response PDU 

if (.._State = send) the XID response PDU has to be sent 
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A.2 List of RLP entity events 



The interface is indicated by hlower, u:upper and m: management. From the formal definition point of view this 
distinction of course is unnecessary. 



event# 


name 


semantic 


interface 


1 


Attach_Req 


Switch to "ADIVI and Attached" 


m 


2 


Connjnd 


Connect indication 


u 


3 


Conn_Conf 


Connect confirm 


u 


4 


Conn_Conf_Neg 


Connect confirm negative 


u 


5 


Conn_Req 


Connect request 


u 


6 


Conn_Resp 


Connect response 


u 


7 


Conn_Resp_Neg 


Connect response negative 


u 


8 


Data_lnd(Data) 


Data transfer indication (user data in Data) 


u 


9 


Data_Req(Data) 


Data transfer request (user data in Data) 


u 


10 


Detach_Req 


Switch to "ADIVI and Detached" 


m 


11 


Discjnd 


Disconnection indication 


u 


12 


Disc Req 


Disconnect request 


u 


13 


DISC(P) 


PDU DISC received (P-bit in P) 


1 


14 


DM(F) 


PDU DM received (F-bit in F) 


1 


15 


Errorjnd 


Error Indication 


u 


16 


LL Data Req 


Data request to lower layer 


1 


17 


LL Data Ind 


Data indication from lower layer 


1 


18 


NULL 


PDU NULL received 


1 


19 


Readyjnd 


Indication that a new PDU may be sent 


m 


20 


Reset_Conf 


Reset confirm 


u 


21 


Resetjnd 


Reset indication 


u 


22 


Reset_Req 


Reset request 


u 


23 


Reset Resp 


Reset response 


u 


24 


RR l(C, P F, NR, NS, Data) 


l-frame RR received 




25 


RNR l(C, P F, NR, NS, Data) 


l-frame RNR received 




26 


REJ l(C, P F, NR, NS, Data) 


l-frame REJ received 




27 


SREJ l(C, P F, NR, NS, Data) 


l-frame SREJ received 




28 


RR(C, P F, NR) 


S-frame RR received 




29 


RNR(C, P F, NR) 


S-frame RNR received 




30 


REJ(C, P F, NR) 


S-frame REJ received 




31 


SREJ(C, P F, NR) 


S-frame SREJ received 




32 


SABM(P) 


PDU SABM received 




33 


UA(F) 


PDU UA received (F-bit in F) 




34 


Ul Req(Data) 


Unnumbered Information transfer request 


u 


35 


UI(C, P F, Data) 


Ul PDU received 


1 


36 


T 


Timeout (Timer of the sender expired) 


m 


37 


Test_Conf(Data) 


Test confirm (received data in Data) 


u 


38 


Test Conf Neg(Data) 


Test confirm negative (received data in Data) 


u 


39 


T RCVR 


Timeout (Timer of the receiver for REJ expired) 


m 


40 


T RCVS(n) 


Timeout (Timer of the receiver for SREJ expired) 


m 


41 


T TEST 


Timeout (Test timer expired) 


m 


42 


T_XID 


Timeout (Xid timer expired) 


m 


43 


Test Req(Data) 


Test request (Test data in Data) 


m 


44 


TEST(C, P_F, Data) 


TEST command/response PDU received 
(C/R-bit in C, P/F-bit in P_F, Data in Data) 


1 


45 


XID Req(Data) 


Exchange ID request 


m 


46 


XID Ind(Data) 


Exchange ID indication 


m 


47 


XID(C, P F, Data) 


XID command/response PDU received 


1 
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System RLP - Overview 



RLP User 



User_Req/Resp 

''Conn_Req, 
Conn_Resp, 
Conn_Resp_Neg, 
Data_Req, 
Disc_Req, 
Reset_Req, 
Reset_Resp, 
UI_Req 



User_lnd/Conf 

-'Conn_lnd, 
Conn_Conf, 
Conn_Conf_Neg, 
Data_ind, 
Disc_lnd, 
Reset_lnd, 
Reset_Conf, 
Ul Ind 



RLP_Entity 



Send_queue 
[LL_Data_Req] 



Manager_Requests 

fAttach_Req, 
Detach_Req, 
Ready_lnd, 
Test_Req, 
Xid_Req 



Manager_lndications 

Error_lnd, 
Test_Conf, 
Test_Conf_Neg, 
Xid Ind 



RLP_Manager 



y^ Receive_queue 
[LL_Data_lnd] 



Lower_Layer_Entity 



0422AF01.DRW 93-03-01 



Figure A.1 
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RLP_Entity 

// RLP process structure 

User_Requests 



Conn_Req, 
Conn_Resp, 
Conn_Resp_Neg; 
Data_Req, 
Disc_Req, 
Reset_Req, 
Reset_Resp, 
LULReq 



User Indications 



Conn_lnd, 
Conn_Conf, 
Con_Conf_Neg, 
Data_lnd, 
Disc_lnd, 
Reset_lnd, 
Reset_Conf, 
LUI_lnd 



RLP Kernel 



// RLP protocol handling 





7 


\ 


PDU_out_queue 




PDU_in_q 


"SABM, ' 








SABM," 


DISC, 








DISC, 


UA, 








UA, 


DM, 








DM, 


RR, 








RR, 


RNR, 








RNR, 


REJ, 








REJ, 


SREJ, 








SREJ, 


RR 1, 








RR 1, 


RNR 1, 








RNR 1, 


REJ 1, 








REJ 1, 


SREJ 1, 








SREJ 1, 


Ul, 


> 




w 


Ul, 


XID, 


/ \ 1 


XID, 


TEST, 
NULL 


/ 




^' 


TEST 



\ / 



Send PDU Receive PDU 



//CRC calculation 



//CRC check and 
// PDU syntax check 



Send_queue 

[LL_Data_Req] 



/ \ 



Manager_Requests 



Attach_Req, 
Detach_Req, 
Ready_lnd, 
Test_Req, 
LXid_Req 



Manager_lndications 



Error_lnd, 
Test_Conf, 
Test_Conf_Neg 
LXid_lnd 



Receive_queue 

[LL_Data_lnd] 



0422AF02.DRW 93-05-25 



Figure A.2 
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c 


Start 


^ 


1 


DM 
DM 
Poll 


State :: 
_FBit:= 
_xchg := 


= idle; 
0; 
= idle; 



J 



r 

RLP entity - state - ADM and Detached 

This is the initial state after power on. 

As long as the RLP entity is "Detached", DISC(P) and/or SABM 
at the lower interface is acted upon by sending DM(P) or DM(1). 
Any other stimulus at the lower interface is ignored. 

This state can be exited only with Attach_Req. 




CD 



0422AF03.DRW 93-02-26 



Figure A.3 
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1 



Conn_Req 



SABM_State 
:= send; 



SABM_Count 
:=0; 



ct^ 
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RLP entity - state 1 - ADM and Attached 

The RLP entity is ready to establish a connection, either by initiating the 
connection itself (Conn_Req) or by responding to an incomming connection 
request (SABM). 

Upon receiving a DISC PDU, the sending of the UA response is initiated. 

7 



SABM 



^ DISC(P) ^ 



Conn Ind 



CD 



UA_State 
:= send; 



UA FBit:=P; 



cz> 




CD 



Figure A.4 
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RLP entity - state 2 - Pending connect request 

Send (up to N2 repetitions) SABM and wait for the corresponding 
UAwithFBit= 1. 

The (sub)state is controlled by the variable SABM_State 
(values idle, send, wait) and SABM_Count (values 0, 1 , ..., N2). 

This state may be exited with a Disconnect Request (see figure 14). 

7 



SABM_Count:= 
SABM Count+ 1; 



Poll_xchg := wait; 



Set(...,T); 



s 
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RLP entity - state 2 - Pending connect request 



from previous page 


Pending C 


onn_Req 


) 


This figure allowes up to N2 repetitions of SABM and 
describes the disconnect and the SABM contention case. 


^ 








error) 














^ < 




DISC(P) ^ 


SABM ^ 


















Poll_xchg := idle; 






Reset(T) 




Reset(T) 




1 






1 




1 


<^BM_Cou^J>^^ 


C Disc_lnd 


\ 


/ 

C Conn_Conf 


1 




1 










UA State :=send; 
UA FBit:=P; 




UA State :=send; 
UA FBit:= 1; 




SABM_State 
:= send; 






1 




1 




CD 


lnit_link_vars 
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RLP entity - state 3 - pending Connect indication 

After having received SABM, the RLP entity is waiting for the Connect 
response. 

The upper layer entity may respond with Conn_Resp or Disc_Req. It is 
assumed that the upper layer entity does not delay the response more 
than T2 msecs. 

The Disconnect request exit is described on a following page (see figure 14). 

7 



y Conn_Resp 



UA_State := send; 



UA FBit := 1; 



Init link vars 




DISC(P) 



< 



I 



Disc Ind 



ci:> 



UA State := send; 



ci> ci:) CD 



UA FBit:=P; 



CD 
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RLP entity - state 4 - Connection established 

This is the data transfer state. The user entity may transmit data by 
fireing Data_Requests. However, he is allowed to do so only if there 
are idle sender slots. 
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The data stored in the send slots will be transmitted at the next possible 
opportunity. 

This state may be exited by a Disconnect Request (see Figure 14). 

7 

























r 


1 


\ Data Req 
/ (data) 




Ready_lnd ^ 


DISC(P) ^ 












S[VD].State := send; 
S[VD].Data := data; 




Send_TXU 


Reset(T); 














VD := VD + 1 
modulo M; 


^^returncode^ 


Reset(T_RCVR) 
Reset all T_RCVS's 














cb 


Send_Data 


\^ Disc_lnd 






o 






d 


UA State := send; 
UA_FBit:=P; 


^^ ^^ 







• see next page 



CD 



Figure A.8 
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• 4 - 

Connection 
established 



from previous p 



■> 



1 



Reset_Req 



Reset(T); 



RLP entity - state 4 - Connection established 

This dagram describes RESET and the Timeout-handling. 

A timeout leads to error recovery by polling. This is controlled by 
the Poll_State variable. The Poll_State transitions are: 

idle -> send <-> wait -> idle 

Zero up to N2 transitions wait->send may occur. 

V 



see next page 



SABM 



\^ T_RGVR \^ 



Reset(T); 



REJ_State 
:= idle ; 



Reset(T_RCVR) 
Reset all T RCVS's 



Reset(T_RCVR) 
Reset all T RCVS's 



SABM_State 

:= send; 
SABM_Count 
■.= 0: 



< 



Reset Ind 



^^ ch 



Reset SREJ-ted 
slots to idle; 



cz> 




PolLState 

:= send; 

PolLCount 

:=Q: 



^ 



Po 


ILState 


:= 


send; 


Poll 


Count := 


Poll 


Count+1: 



^ 
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RLP entity - state 4 - Connection established 

This diagram describes the handling of l-frames and S-frames 
(PDUs RR, RNR, REJ, SREJ and RR_I, RNR_I, REJ_I, SREJ_ 



If the frame contains user information, this is handled by the l-Handler. 
The supervisory information is handled by the S-handler. 



Connection .* A frame with an unsolicited F-bit is ignored, 
established ..•** */ 



from previous page 



> 



RRJ(C,P, 
NR,NS,Data' 



RNRJ(C 
NR.NS 



(C,P/ |rEJ_I(C,P, / |SREJJ(C,P/ 
.DatX JNR.NS DataK JNR.NS.DataK 




/* sets returncode if the 
frame has to be ignored */ 



S handler 
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RLP entity - state 5 - Disconnect initiated 

This state is exited only after a valid response is received 
or after N2 timeouts. 

7 



^ DM(F) ^ 



DISC(P) 







Reset(T); 




UA_State 

:= send; 

UA_FBit 

:=P; 



/(DISC_PBit=1) 
i and 

\(Poll_xchg = wait) 



Poll_xchg := wait; 



DISC_State:= 

wait; 
DISC_Count:= 
DISC Count + 1 



I 



Set(....,T); 
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Poll_xchg := idle; 




DISC_State 
:= send; 



s 



Figure A.11 
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RLP entity - state 6 - pending Reset Request 

Send (up to N2 repetitions) SABIVI and wait for the responding UA with FBit=1 . 

The substate is controlled by the variable SABM_State (values idle, send, wait; 
and SABM_Count (values 0..N2). 

This state may be exited with a Disconnect Request (see Figure 14). 



Ready_lnd 




DISC(P 



I 



SABM 



Reset(T); 



Reset(T); 



Disc Ind 



SABM 



i 



Reset Conf 



UA_State := 




UA_State := 


send; 




send; 


UA FBit:=P; 




UA FBit:=1; 



CD 




Init link vars 



Init link vars 



SABM_State 
:= wait; 



CD 



<±) "^ 



ct> 



SABM_Count := 
SABM Count+ 1 



Poll_xchg := wait; 



Set(...,T); 



^ 
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RLP entity - state 7 - pending Reset Indication 

After having received SABM and having indicated Reset, the RLP 
entity is waiting for the Reset_Response. 




> 



Reset_Resp 



UA_State := 

send; 
UA FBit:= 1; 



Init link vars 



CD 



The upper layer entity may respond with Reset_Resp or Disc_Req. 
It is assumed, that the upper layer entity does not delay the response 
more than T2 msecs. 

The Disconnect Request is described on a following page 
(see Figure 14). 

V 




DISC(P) 



^Di 



I 



isc Ind 



UA_State := 

send; 
UA FBit:= P; 



CD 
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This is the error handling 
when there is no action 
from the remote end 
after N2 repetitions. 
The error handling 
and the state transition 
depends on the situation 
e.g. ADM in case of DISC 
V 



r 

Detach Request 

Detach is allowed at 
any time. 

The Detach Request 
is used to reset the RLP 
entity to state 0, e.g. if 
the physical connection 
is lost. 
V 



Disconnect Request 

Disconnect is used to release a connection. 

The actions to be executed in these cases are: 
reset the timer, activate sending of the DISC PDU. 

The P-bit in the DISC command is set to 

one or zero, depending on the Poll_xchg state. 

7 
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1 



Disc_Req 



Reset(T); 



DISC_State := 

send; 
DISC_Count:=0; 




Poll_xchg 



idle 



DISC_PBit:= 1; 



else 



DISC PBit:=0; 



CD Ct> 



Figure A.14 
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Ul handling (ULReq,UI) 

UI_Requests are controlled using the state variable UI_State. The values 
(state transitions) are: idle -> send -> idle 

It is assumed that the upper layer entity issues an UI_Req only if the RLP 
entity's UI_State is idle. The Ul data is stored in the variable UI_Data. 

The UI_PDU is generated at the next possible opportunity, i.e. after 
the higher priviledged PDUs (TEST PDUs, XID PDUs, if any) have been 
transmitted. 

7 




Ul Data := data; 



ULState :=send; 



Ul PBit:=0; 



C3 



/* 

Ul frames with P-Bit set to 
will not be genereted. 
(implementation decision). 

7 
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XID handling (XID_Req, XID) 

XID requests are controlled using the state variable XID_C_State and 
XID_R_State. The state transitions being used are: 

idle -> send -> wait -> idle. 

The XID data is stored in the variable XID_C_Data. 



XID_C_State 
:= send; 



XID_Count 
:=0; 



XID_C_PBit 
:= 1; 




XID_C_Data 
:= data; 




/* 



The action on a received XID command PDU depends on the state variable XID_C_State. In the contation case the 
XID Command is sent again after a certain delay, depending on the 'location' of the RLP entity. 

The XID command/response PDU is sent at the earliest possible opportunity, next after a possible pending TEST PDU 
(see procedure SEND_TXU) The value of the timer should be T1 ms in the Mobile Station, it should be twice this value 
in the Interworking Unit. This scheme is used to avoid repetinion of contentions. 

V 
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/* 

TEST handling (TEST_Req, TEST_PDU, TESTJmeout) 




TEST_C_Data 
:= data; 



TEST_R_Data 
:= data; 



Reset(T_TEST); 



cz> 




Poll_xchg:=idle; 



TEST_C_State 
:= send; 



o 




< 



>=N2 



TEST_Conf_neg 
no_response) 



TEST_Count:= 
TEST Count+1 



Poll_xchg:=idle; 



TEST_C_State 
:=idle; 



cz> cz> 




TEST C Data 



else 



TEST_Conf_neg 
(data_error) 



TEST C State := TEST C State 



idle; 



idle; 
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Process Receive PDU 



c 


Start 





1 


Initialisations 



Receive a block, test CRC and indicate PDU to 
RLP Kernel if and only if CRC is ok, otherwise 
ignore the invalid block. 

V 
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Receive a block, test CRC and indicate PDU to RLP Kernel 

V 



< 



RR I 



RR_I(C,P, 
NR,NS,Data) 



< 



RR 



RR(C,P,NR) 



< 



TEST 



TEST 
(C,P_F,Data) 



RNR I 



RNR_I(C,P, 
NR,NS,Data) 



REJ I 



REJ_I(C,P, 
NR,NS,Data) 



RNR 



RNR(C,P,NR) 



REJ 



REJ(C,P,NR) 



XID 



XID 
(C,P_F,Data) 



Ul 



UI(C,P_F,Data) 



SREJ I 



SREJ_I(C,P, 
NR,NS,Data) 



o o o o 



SREJ 



SREJ(C,P,NR) 



o o o o 



else 



r ignore 
block V 



o o o o 
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Process Send PDU 



Q5J73 



Initialisations 



/* 

Generate CRC and forward complete PDU 

to lower layer to send it. 

*/ 






\ SABM \ DISC(P) \ UA(F) \ 



DM(F) 





\ RR_I(C,P, I \ RNR_I(C,P, I \REJ_I(C,P, I "^ 
y^NR,NS,Data)| y^NR,NS,Data)| y^NR,NS,Data)| y^t 





.SREJ_I(C,P, 
'^NR.NS.Data) 





\rR(C,P,NR) \rNR(C,P,NR) \r 





1EJ(C,P,NR) 



>REJ(C,P,NR) 





\ TEST I \ xTd I V 
XC,P_F,Data) yfCP F,Dataj ^ 





Ul 



rC,P_F, Data, 





calculate CRC 



I 



NULL 




LL_Data_Req 
(bloc 
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Initialise link variables - This procedure is called if the link is established or the link is reset. 

7 



( lnit_link_vars j ( lnit_slots j 



Ackn_State := idle; 



n :=0; 



PolLState := idle; 
Poll Count:= 0; 



R[n]. state := idle; 



Poll_xchg := idle; 
REJ State := idle; 



S[n]. state := idle; 



SABM_State := idle 
DISC State := idle; 



n := n + 1 ; 



RRReady := true; 



VA :=0; 
VR :=0; 




VS :=0; 
VD :=0; 



InJt slots 




There are M data receiver slots and M data sender slots (M <= 62). 

The receiver states are: idle, rcvd, send, wait. 

State = idle means: nothing received (with this number). 

State = rcvd means: data received, to be delivered and acknowledged only if in sequence. 

If delivered, the state becomes idle again. 
State = send means: pending retransmission request for this block. 
State = wait means : waiting for receiption of requested block. 



The sender slot states are: 



idle, send, wait. 



State = idle means: nothing to do, slot may be used (again). 
State = send means: send data at the next possible opportunity. 
State = wait means: wait for the acknowledgement 



V 
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( Lhandler j 



returncode := 



returncode : 



/* ignore 
improper 
frame */ 





Handling the I part of the received frame 
(PDU isRR,RNR,REJorSREJ). 

The P-bit must not be set in l-frames. 

The sequence number NS must be within 
the current window. 

The returncode informs, if the frame has 
been regarded as improper. 

7 



<NS withins^yes 
window ?^ 

_x 



returncode := 




/* ignore 
improper 
frame */ 
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R[VR].state 
:= rcvd; 






R[VR .data 
:= Data; 






Deliver all 

in-sequence 

l-frames 






REJ State 
:=idle; 






ACKN_State 
:= send; 



1 

SRE 
Use^v 



<is SREJx^no 



^R[N$].$tate^no ^s REJv^no 
^used ?^^ 



= wait? 
^es 



Reset 
T_RCVS[NS]; 



R[NS] 



state 
rcvd; 



R[NS].data 
:= Data; 




Mark missing 
l-frames to 
beSREJted 






REJ_State 
:= send; 



returncode := 1; 




/* ignore out- 

of-sequence 

l-frame */ 




Figure A.22 
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Deliver all in-sequence l-frames 



mark all missing l-frames 



Indicate all already received in-sequence 
information blocks. There may be more 
than one block which has to be indicated 
due to successful selective recovery. 

V 



All missing l-frames "between" 
VR an NS have to be marked 
if their state is idle. 

V 



(Deliver all in- ^ 
sequence l-framesy 



< 



Data_lnd 
(R[VR].Data) 



R[VR].state 
:=idle; 



VR := VR + 1 
modulo M; 




= rcvd 



C Mark missing ^ 
IJrames y 



n :=VR; 




= idle 



R[VR].state 
:= send; 



n := n + 1 
modulo M; 
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Handling the S part of the received frame 
(PDU is RR, RNR, REJ or SREJ or l-frames piggy- 
backed with supervisory information).. 

The sequence number NR must be within the set 
of not yet acknowledged l-frames or it must be the 
next possible frame number. This condition is already 
checked, before the S_handler is called (see Figure 10). 




SREJ 
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Advance the lower 
window edge 

*/ 



Set the sender slot 
states to send again 
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Send_Data is called, if there is a send opportunity. 
It decides upon RR, RNR, REJ or SREJ, howeverfirst 
it is checked, if an UA Response must be send. 



Send 

RRorRR_l 

Resp 



1 Send T 

RNRorRNR_l 

I Resp I 







/* 

Send RR or RR_I Response is described in Figure 27, 

Send RNR or RNR_I Response also is described in Figure 27, 

Send REJ or REJ_I Command can be found in Figure 29 





get slot 
number n 












1 Send 1 
SREJorSREJ 1 
1 Cmd(n) 1 



1 

<- local s. no 
receiver ^— 
-read^?^ 
Jyes 



Send 

RRorRR_l 

Cmd 





1 Send r 
RNRorRNR_l 
I Cmd I 
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Send SREJ or SREJ_I Command (n) is described in Figure 30, 

Send RR or RR_I Command is described in Figure 28, 

Send RNR or RNR_I Command also can be found in Figure 28. 

V 



Figure A.26 
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(Send XX or \ 
XX_IResp J 




Send XX or XX_I response PDU with F-Bit set to one. 
XXmaybeRR orRNR. 
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Send XX or XX_I Command PDU. 

XX maybe RR or RNR. 

Supervisory frames may be candidates for DTX. 



Poll_Count:= 
Poll Count+1: 



PolLState 
:= wait; 



Poll_xchg 
:= wait; 



Set(...,T) 




< Remote^ pk- 
receiver^>— 
ready ?^ 
_>Qes 
XXI \ 



(1,0,VR,VS, 
SfVSjData) 



I 



ACKN_State 
:=idle; 



S[VS].State 
:= wait; 



VS := VS + 1 
modulo M; 



Set(...,T) 





Supervisory only frames 
are candidates for DTX. 

As shown here DTX may 
be indicated for the first 
redundant S-frame. Other 
strategies are possible. 

V 



DTX_VR 
:= VR; 
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= wait 




Send REJ or REJ_I Command PDU. 



REJ 

(1,1,VR) 



ACKN_State 
:=idle; 



REJ_State 
:= wait; 



1 

Set(...,T_RCVR) 



Poll_Count:= 
Poll Count+1; 
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o 




<^ 



emoie^ 
receiver ^^ 
ready 7-^ 

ryes 

REJJ \ 
(1,0,VR,VS, 
SfVSjData)/ 



no 



I 



ACKN_State 
:= idle; 



1 




1 




PolLState 
:= wait; 




REJ_State 
:= wait; 




1 




1 


R 


Poll_xchg 
:= wait; 




Set(...,T_RCV 


1 




1 


Set(...,T) 




S[VS].State 
:= wait; 





VS := VS + 1 
modulo M; 



Set(...,T) 




Figure A.29 



<D 




REJ 
(1,0,VR) 



> 



ACKN_State 
:=idle; 



REJ_State 
:= wait; 



Set(...,T_RCVR) 
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(SendSREJor ^ 
SREJ_I Cmd(n)y 




Send SREJ orSREJ_l Command PDU. 



wait 



<D 



else 



SREJ 

(1,1,n) 



R[n]. State 
:= wait; 



Set(...,T_RCVS[n]) 



Poll_Count:= 
Poll Count+1; 



PolLState 
:= wait; 



Poll_xchg 
:= wait; 



Set(...,T) 





yes 

< Remote *\^PiQ 
receiver ^^ — 
r^adp^'^ 

lyes 
SRbJ_l 
(1,0,n,VS, 



SfVSI.Data 



1 



> 



R[n]. State 
:= wait;; 



Set(...,T_RCVS[n]) 



S[VS]. State 
:= wait; 



VS := VS + 1 
modulo M; 



Set(...,T) 





SREJ 

(1,0,n) 



R[n]. State 
:= wait; 



Set(...,T_RCVS[n]) 
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Ul 
(1,0, ULData) 



> 



ULState 
:=idle; 



returncode := 1; 




0422AF31.DRW 93-03-01 



Send a pending TEST, XID or UIPDU 
(or do nothing, if no PDU is pending). 

The returncode indicates if something 
has been sent. 

*/ 



TC 



® 



TEST 

{0,TEST_R_FBit, 

TEST_R_Data) 



I 



TEST_R_State 
:=idle; 



returncode := 1; 





XID 
(0, 1,XID_R_Data) 



y^ 



XID_R_State 
:=idle; 



returncode := 1; 




.TEST_C_PBit=1 yes 
<^ and >--(TXU1 

PolJxchQ^wait 




TEST 

(1,TEST_C_PBit, 

TEST_C_Data) 




r PRit ^^^. 


= 1 


L'_rDii ^^^ 


1 


< 


PolLxchg 
:= wait; 


1 




XID 
(1,1,XID_C_Data) 



> 



XID_C_State 
:= wait; 



Set(...,T_XID); 



Poll_xchg := wait; 



returncode := 




Figure A.31 
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